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Abstract 


This document provides a model of information needed by the Routing 
and Wavelength Assignment (RWA) process in Wavelength Switched 
Optical Networks (WSONs). The purpose of the information described 
in this model is to facilitate constrained optical path computation 
in WSONs. This model takes into account compatibility constraints 
between WSON signal attributes and network elements but does not 
include constraints due to optical impairments. Aspects of this 
information that may be of use to other technologies utilizing a 
GMPLS control plane are discussed. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7446. 


Lee, et al. Informational [Page 1] 


RFC 7446 WSON Information Model February 2015 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 


carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 


include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Table of Contents 


Lis? 3EntrEoductlon--a- ee Re RUE I eu qp ur PEDI OM eiie 3 
Do. SEELMINOLOGY Be te M esce e sues Poste e em er RR Eee Re M E SR E ms 3 
3. Routing and Wavelength Assignment Information Model ............. 3 
3.1. Dynamic and Relatively Static Information .................. 4 

4. Node-intormation.. (General) una. d san eS wa BE Re 4 
4.1. Connectivity Matrix ce arti oe ne Meebo eo BES SU ae URS RUE e 5 

5, Node Information (WSON-SpecifrGC) 2 un. sen eaa ssi e ere enw tes: ee 5 
5.1. Resource Accessibility/Availability .................... 000s 7 
5.2. Resource Signal Constraints and Processing Capabilities LIT 
5.3. Compatibility and Capability Details sce bi essen 12 
5.3.1. Shared Input or Output Indication 2.0. sed eee ee 12 

5432. Optical. Interface Class List sense Re 12 

55.33. ACCeptable Client - Signal List: (24:99 5-5 4&8 REN XS 13 

Budd (Processing. Capability List: e. IRA sr mV. E 13 

6. Lrink-Inforiüation (General). 2... 22322 ewe See ae ER eer 13 
6.1. Administrative: :GLOUD cc. Ri rare 14 
6.2. Interface Switching Capability Descriptor ................. 14 
6.3. Link Protection. Type (for THES Link) „ar. een y eye 14 
6.4. Shared Risk Link Group Information ................. eee 14 
6,54, Traffic Engineering Metric woe eS os gee es uere a ee eee 15 
6.6. Port, Label. ReserlekEiöns Arsen eel od een re 15 
6.6.1. Port-Wavelength Exclusivity Example ................ 17 

7. Dynamic Components of the Information Model .................... 18 
7.1. Dynamic Link Information (General) ................. eee 19 
7.2. Dynamic Node Information (WSON Specific) .................. 19 

84 (Security.consderatiols.--iwueeeduedo us ule y esee uri hates RU RUE E “eevee eis 19 
95. References nen uude beads eh ee ruere e ear 20 
9.1. Normative References... 2911.4. 2522322224 003 ue EE RUE RUE 20 
9:2. Informative ReferencesS"t.is.l.w.a Roh bt huge x yere Er EE 21 
ConbrrbütOES aa cette Sustain ej cise chee ui enc i INA IMS uM DIE T ee eh esee 22 
Aüutshors^ »Addrssses: «aee are hp eed RE eil cca eeu see dece E 23 
Lee, et al. Informational [Page 2] 


RFC 7446 WSON Information Model February 2015 


Les 


Introduction 


The purpose of the WSON information model described in this document 
is to facilitate constrained optical path computation, and as such it 
is not a general-purpose network management information model. This 
constraint is frequently referred to as the "wavelength continuity" 
constraint, and the corresponding constrained optical path 
computation is known as the Routing and Wavelength Assignment (RWA) 
problem. Hence, the information model must provide sufficient 
topology and wavelength restriction and availability information to 
support this computation. More details on the RWA process and WSON 
subsystems and their properties can be found in [RFC6163]. The model 
defined here includes constraints between WSON signal attributes and 
network elements but does not include optical impairments. 


In addition to presenting an information model suitable for path 
computation in WSON, this document also highlights model aspects that 
may have general applicability to other technologies utilizing a 
GMPLS control plane. The portion of the information model applicable 
to technologies beyond WSON is referred to as "general" to 
distinguish it from the "WSON-specific" portion that is applicable 
only to WSON technology. 


Terminology 


Refer to [RFC6163] for definitions of Reconfigurable Optical Add/Drop 
Multiplexer (ROADM), RWA, Wavelength Conversion, Wavelength Division 

Multiplexing (WDM), WSON, and other related terminology used in this 

document. 


Routing and Wavelength Assignment Information Model 


The WSON RWA information model in this document comprises four 
categories of information. The categories are independent of whether 
the information comes from a switching subsystem or from a line 
subsystem -- a switching subsystem refers to WSON nodes such as a 
ROADM or an Optical Add/Drop Multiplexer (OADM), and a line subsystem 
refers to devices such as WDM or Optical Amplifier. The categories 
are these: 


o Node Information 
o Link Information 
o Dynamic Node Information 


o Dynamic Link Information 
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Note that this is roughly the categorization used in Section 7 of 
[6.7715]. 


In the following, where applicable, the Reduced Backus-Naur Form 
(RBNF) syntax of [RBNF] is used to aid in defining the RWA 
information model. 


3.1. Dynamic and Relatively Static Information 


All the RWA information of concern in a WSON network is subject to 
change over time. Equipment can be upgraded; links may be placed in 
or out of service and the like. However, from the point of view of 
RWA computations, there is a difference between information that can 
change with each successive connection establishment in the network 
and information that is relatively static and independent of 
connection establishment. A key example of the former is link 
wavelength usage since this can change with connection setup/teardown 
and this information is a key input to the RWA process. Examples of 
relatively static information are the potential port connectivity of 
a WDM ROADM, and the channel spacing on a WDM link. 


This document separates, where possible, dynamic and static 
information so that these can be kept separate in possible encodings. 
This allows for separate updates of these two types of information, 
thereby reducing processing and traffic load caused by the timely 
distribution of the more dynamic RWA WSON information. 


4. Node Information (General) 


The node information described here contains the relatively static 
information related to a WSON node. This includes connectivity 
constraints amongst ports and wavelengths since WSON switches can 
exhibit asymmetric switching properties. Additional information 
could include properties of wavelength converters in the node, if any 
are present. In [Switch] it was shown that the wavelength 
connectivity constraints for a large class of practical WSON devices 
can be modeled via switched and fixed connectivity matrices along 
with corresponding switched and fixed port constraints. These 
connectivity matrices are included with the node information, while 
the switched and fixed port wavelength constraints are included with 
the link information. 


Formally, 
«Node Information» ::- «Node ID» [<ConnectivityMatrix>...] 


Where the Node ID would be an appropriate identifier for the node 
within the WSON RWA context. 
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Note that multiple connectivity matrices are allowed and hence can 
fully support the most-general cases enumerated in [Switch]. 


4.1. Connectivity Matrix 


The connectivity matrix (ConnectivityMatrix) represents either the 
potential connectivity matrix for asymmetric switches (e.g., ROADMs 
and such) or fixed connectivity for an asymmetric device such as a 
multiplexer. Note that this matrix does not represent any particular 
internal blocking behavior but indicates which input ports and 
wavelengths could possibly be connected to a particular output port. 
For a switch or ROADM, representing blocking that is dependent on the 
internal state is beyond the scope of this document. Due to its 
highly implementation-dependent nature, it would most likely not be 
subject to standardization in the future. The connectivity matrix is 
a conceptual M by N matrix representing the potential switched or 
fixed connectivity, where M represents the number of input ports and 
N the number of output ports. This is a "conceptual" matrix since 
the matrix tends to exhibit structure that allows for very compact 
representations that are useful for both transmission and path 
computation. 


Note that the connectivity matrix information element can be useful 
in any technology context where asymmetric switches are utilized. 


«ConnectivityMatrix» ::= «MatrixID» 
<ConnType> 
<Matrix> 

Where 


<MatrixID> is a unique identifier for the matrix. 


<ConnType> can be either 0 or 1 depending upon whether the 
connectivity is either fixed or switched. 


<Matrix> represents the fixed or switched connectivity in that 
Matrix(i, j) = 0 or 1 depending on whether input port i can connect 
to output port j for one or more wavelengths. 


5. Node Information (WSON Specific) 
As discussed in [RFC6163], a WSON node may contain electro-optical 
subsystems such as regenerators, wavelength converters or entire 


switching subsystems. The model present here can be used in 
characterizing the accessibility and availability of limited 
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resources such as regenerators or wavelength converters as well as 
WSON signal attribute constraints of electro-optical subsystems. As 
such, this information element is fairly specific to WSON 
technologies. 


In this document, the term "resource" is used to refer to a physical 
component of a WSON node such as a regenerator or a wavelength 
converter. Multiple instances of such components are often present 


within a single WSON node. This term is not to be confused with the 
concept of forwarding or switching resources such as bandwidth or 
lambdas. 


A WSON node may include regenerators or wavelength converters 
arranged in a shared pool. As discussed in [RFC6163], a WSON node 
can also include WDM switches that use optical-electronic-optical 
(OEO) processing. There are a number of different approaches used in 
the design of WDM switches containing regenerator or converter pools. 
However, from the point of view of path computation, the following 
need to be known: 


1. The nodes that support regeneration or wavelength conversion. 


2. The accessibility and availability of a wavelength converter to 
convert from a given input wavelength on a particular input port 
to a desired output wavelength on a particular output port. 


3. Limitations on the types of signals that can be converted and the 
conversions that can be performed. 


Since resources tend to be packaged together in blocks of similar 
devices, e.g., on line cards or other types of modules, the 
fundamental unit of identifiable resource in this document is the 
"resource block". 


A resource block is a collection of resources from the same WSON node 
that are grouped together for administrative reasons and for ease of 
encoding in the protocols. All resources in the same resource block 
behave in the same way and have similar characteristics relevant to 
the optical system, e.g., processing properties, accessibility, etc. 


A resource pool is a collection of resource blocks for the purpose of 
representing throughput or cross-connect capabilities in a WSON node. 
A resource pool associates input ports or links on the node with 
output ports or links and is used to indicate how signals may be 
passed from an input port or link to an output port or link by way of 
a resource block (in other words, by way of a resource). A resource 
pool may, therefore, be modeled as a matrix. 
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A resource block may be present in multiple resource pools. 
This leads to the following formal high-level model: 
«Node Information» ::- «Node ID» 
[<ConnectivityMatrix>...] 
[<ResourcePool>] 
Where 
<ResourcePool> ::= <ResourceBlockInfo>... 
[<ResourceAccessibility>...] 
[<ResourceWaveConstraints>...] 
[<RBPoolState>] 


First, the accessibility of resource blocks is addressed; then, their 
properties are discussed. 


5.1. Resource Accessibility/Availability 


A similar technique as used to model ROADMs, and optical switches can 
be used to model regenerator/converter accessibility. This technique 
was generally discussed in [RFC6163] and consisted of a matrix to 
indicate possible connectivity along with wavelength constraints for 
links/ports. Since regenerators or wavelength converters may be 
considered a scarce resource, it is desirable that the model include, 
if desired, the usage state (availability) of individual regenerators 
or converters in the pool. Models that incorporate more state to 
further reveal blocking conditions on input or output to particular 
converters are for further study and not included here. 


The three-stage model is shown schematically in Figures 1 and 2. The 
difference between the two figures is that in Figure 1 it’s assumed 
that each signal that can get to a resource block may do so, while in 
Figure 2 the access to sets of resource blocks is via a shared fiber 
that imposes its own wavelength collision constraint. Figure 1 shows 
that there can be more than one input to each resource block since 
each input represents a single wavelength signal, while Figure 2 
shows a single WDM input or output, e.g., a fiber, to/from each set 
of blocks. 
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This model assumes N input ports (fibers), P resource blocks 
containing one or more identical resources (e.g., wavelength 
converters), and M output ports (fibers). Since not all input ports 
can necessarily reach each resource block, the model starts with a 
resource pool input matrix RI(i,p) = {0,1} depending on whether input 
port i can potentially reach resource block p. 


Since not all wavelengths can necessarily reach all the resources or 
the resources may have limited input wavelength range, the model has 
a set of relatively static input port constraints for each resource. 
In addition, if the access to a set of resource blocks is via a 
shared fiber (Figure 2), this would impose a dynamic wavelength 
availability constraint on that shared fiber. The resource block 
input port constraint is modeled via a static wavelength set 
mechanism, and the case of shared access to a set of blocks is 
modeled via a dynamic wavelength set mechanism. 


Next, a state vector RA(j) = {0,...,k} is used to track the number of 
resources in resource block j in use. This is the only state kept in 
the resource pool model. This state is not necessary for modeling 
"fixed" transponder system or full OEO switches with WDM interfaces, 
i.e., systems where there is no sharing. 


After that, a set of static resource output wavelength constraints 
and possibly dynamic shared output fiber constraints maybe used. The 
static constraints indicate what wavelengths a particular resource 
block can generate or is restricted to generating, e.g., a fixed 
regenerator would be limited to a single lambda. The dynamic 
constraints would be used in the case where a single shared fiber is 
used to output the resource block (Figure 2). 


Finally, to complete the model, a resource pool output matrix RE(p,k) 


= (0,1) depending on whether the output from resource block p can 
reach output port k, may be used. 
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Il +------------- + +------------- + O1 
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Input wavelength Output wavelength 
constraints for constraints for 
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Note: Rb is a resource block. 


Figure 1: Schematic Diagram of the Resource Pool Model 
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lf qcexeeeLee-E4- + qp------———--2-—- + O1 
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| Connection | + + | Connection | 
| Matrix | +-| Rb #3 |======= | Matrix 
| | ee * | | 
| | | | 
| | | | 
| | | | 
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Single (shared) fibers for block input and output 
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availability for availability for 
each block input fiber each block output fiber 


Note: Rb is a resource block. 


Figure 2: Schematic Diagram of the Resource Pool Model with 
Shared Block Accessibility 


Formally, the model can be specified as: 


<ResourceAccessibility> ::= <PoolInputMatrix> 
<PoolOutputMatrix> 
<ResourceWaveConstraints> ::= <InputWaveConstraints> 


<OutputWaveConstraints> 


<RBSharedAccessWaveAvailability> ::= [<InAvailableWavelengths>] 


[<OutAvailableWavelengths>] 
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«RBPoolState» ::- <ResourceBlockID> 
«NumResourcesInUse» 
[<RBSharedAccessWaveAvailability>] 
[<RBPoolState>] 
Note that, except for <RBPoolState>, all the components of 
<ResourcePool> are relatively static. Also, the 
<InAvailableWavelengths> and <OutAvailableWavelengths> are only used 
in the cases of shared input or output access to the particular 
block. See the resource block information in the next section for 
how this is specified. 
5.2. Resource Signal Constraints and Processing Capabilities 
The wavelength conversion abilities of a resource (e.g., regenerator, 
wavelength converter) were modeled in the <OutputWaveConstraints> 
previously discussed. As discussed in [RFC6163], the constraints on 
an electro-optical resource can be modeled in terms of input 
constraints, processing capabilities, and output constraints: 
«ResourceBlockInfo» ::= <ResourceBlockSet> 
[<InputConstraints>] 
[<ProcessingCapabilities>] 
[<OutputConstraints>] 
Where <ResourceBlockSet> is a list of resource block identifiers 
with the same characteristics. If this set is missing, the 
constraints are applied to the entire network element. 
The <InputConstraints> are constraints are based on signal 
compatibility and/or shared access constraint indication. The 
details of these constraints are defined in Section 5.3. 
<InputConstraints> ::= <SharedInput> 
[<OpticalInterfaceClassList>] 
[<ClientSignalList>] 
The <ProcessingCapabilities> are important operations that the 


resource (or network element) can perform on the signal. The details 
of these capabilities are defined in Section 5.3. 
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<ProcessingCapabilities> ::- [<NumResources>] 
[<RegenerationCapabilities>] 
[<FaultPerfMon>] 
[<VendorSpecific>] 
The <OutputConstraints> are either restrictions on the properties of 
the signal leaving the block, options concerning the signal 
properties when leaving the resource, or shared fiber output 
constraint indication. 
<OutputConstraints> := <SharedOutput> 
[<OpticalInterfaceClassList>] 
[<ClientSignalList>] 
5.3. Compatibility and Capability Details 
5.3.1. Shared Input or Output Indication 
As discussed in Section 5.2 and shown in Figure 2, the input or 
output access to a resource block may be via a shared fiber. The 


<SharedInput> and <SharedOutput> elements are indicators for this 
condition with respect to the block being described. 


5.3.2. Optical Interface Class List 
«OpticallnterfaceClassList» ::= <OpticallnterfaceClass> 


The Optical Interface Class is a unique number that identifies all 
information related to optical characteristics of a physical 
interface. The class may include other optical parameters related to 
other interface properties. A class always includes signal 
compatibility information. 


The content of each class is out of the scope of this document and 
can be defined by other entities (e.g., the ITU, optical equipment 
vendors, etc.). 


Since even current implementation of physical interfaces may support 
different optical characteristics, a single interface may support 
multiple interface classes. Which optical interface class is used 
among all the ones available for an interface is out of the scope of 
this document but is an output of the RWA process. 
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5.3.3. Acceptable Client Signal List 
The list is simply: 
<ClientSignalList>::=[<G-PID>]... 
Where the Generalized Protocol Identifiers (G-PID) object represents 
one of the IETF-standardized G-PID values as defined in [RFC3471] and 
[RFC4328]. 
5.3.4. Processing Capability List 
The ProcessingCapabilities are defined in Section 5.2. 
The processing capability list sub-TLV is a list of processing 


functions that the WSON network element (NE) can perform on the 
signal including: 


1. number of resources within the block 
2. regeneration capability 

3. fault and performance monitoring 

4.  vendor-specific capability 


Note that the code points for fault and performance monitoring and 
vendor-specific capability are subject to further study. 


6. Link Information (General) 


MPLS-TE routing protocol extensions for OSPF [RFC3630] and IS-IS 
[RFC5305], along with GMPLS routing protocol extensions for OSPF 
[RFC4203] and IS-IS [RFC5307] provide the bulk of the relatively 
static link information needed by the RWA process. However, WSONs 
bring in additional link-related constraints. These stem from 
characterizing WDM line systems, restricting laser transmitter 
tuning, and switching subsystem port wavelength constraints, e.g., 
"colored" ROADM drop ports. 


The following syntax summarizes both information from existing GMPLS 


routing protocols and new information that may be needed by the RWA 
process. 
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«LinkInfo» ::= <LinkID> 
[<AdministrativeGroup>] 
[<InterfaceCapDesc>] 
[<Protection>] 
[<SRLG>...] 
[<TrafficEngineeringMetric>] 
[<PortLabelRestriction>...] 
Note that these additional link characteristics only apply to line- 
side ports of a WDM system or add/drop ports pertaining to the 
resource pool (e.g., regenerator or wavelength converter pool). The 
advertisement of input/output tributary ports is not intended here. 
6.1. Administrative Group 
Administrative Group: Defined in [RFC3630] and extended for MPLS-TE 
[RFC7308]. Each set bit corresponds to one administrative group 
assigned to the interface. A link may belong to multiple groups. 
This is a configured quantity and can be used to influence routing 
decisions. 
6.2. Interface Switching Capability Descriptor 
InterfaceSwCapDesc: Defined in [RFC4202]; lets us know the different 
switching capabilities on this GMPLS interface. In both [RFC4203] 
and [RFC5307], this information gets combined with the maximum Link 
State Protocol Data Unit (LSP) bandwidth that can be used on this 
link at eight different priority levels. 
6.3. Link Protection Type (for This Link) 
Protection: Defined in [RFC4202] and implemented in [RFC4203] and 
[RFC5307]. Used to indicate what protection, if any, is guarding 
this link. 
6.4. Shared Risk Link Group Information 
SRLG: Defined in [RFC4202] and implemented in [RFC4203] and 
[RFC5307]. This allows for the grouping of links into shared risk 


groups, i.e., those links that are likely, for some reason, to fail 
at the same time. 
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6.5. Traffic Engineering Metric 


TrafficEngineeringMetric: Defined in [RFC3630] and [RFC5305]. This 
allows for the identification of a data-channel link metric value for 
traffic engineering that is separate from the metric used for path 
cost computation of the control plane. 


Note that multiple "link metric values" could find use in optical 
networks; however, it would be more useful to the RWA process to 
assign these specific meanings such as "link mile" metric, 
"probability of failure" metric, etc. 


6.6. Port Label Restrictions 
Port label restrictions could be applied generally to any label types 
in GMPLS by adding new kinds of restrictions.  Wavelength is a type 
of label. 
Port label (wavelength) restrictions (PortLabelRestriction) model the 
label (wavelength) restrictions that the link and various optical 
devices, such as Optical Cross-Connects (OXCs), ROADMs, and waveband 
multiplexers, may impose on a port. These restrictions tell us what 
wavelength may or may not be used on a link and are relatively 
static. This plays an important role in fully characterizing a WSON 
switching device [Switch]. Port wavelength restrictions are 
specified relative to the port in general or to a specific 
connectivity matrix (Section 4.1). [Switch] gives an example where 
both switch and fixed connectivity matrices are used and both types 
of constraints occur on the same port. 
<PortLabelRestriction> ::- <MatrixID> 

<RestrictionType> 


<Restriction parameters list> 


<Restriction parameters list> ::= 
<Simple label restriction parameters> | 
<Channel count restriction parameters> | 
<Label range restriction parameters> | 
<Simple+channel restriction parameters» | 


<Exclusive label restriction parameters> 
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«Simple label restriction parameters» ::- <LabelSet> 
«Channel count restriction parameters» ::= <MaxNumChannels> 
«Label range restriction parameters» ::= <MaxLabelRange> 

(<LabelSet> ...) 
<Simple+tchannel restriction parameters» ::- <MaxNumChannels> 

(<LabelSet> ...) 

«Exclusive label restriction parameters» ::= <LabelSet> 
Where 


MatrixID is the ID of the corresponding connectivity matrix 
4.1). 


(Section 


The RestrictionType parameter is used to specify general port 
restrictions and matrix-specific restrictions. It can take the 


following values and meanings: 


SIMPLE LABEL: Simple label (wavelength) set restriction; the 


LabelSet parameter is required. 


CHANNEL COUNT: The number of channels is restricted to be 


less 


than or equal to the MaxNumChannels parameter (which is 


required). 


LABEL RANGE: Used to indicate a restriction on a range of labels 
that can be switched. For example, a waveband device with a 
tunable center frequency and passband. This constraint is 
characterized by the MaxLabelRange parameter, which indicates 
the maximum range of the labels, e.g., which may represent a 
waveband in terms of channels. Note that an additional 
parameter can be used to indicate the overall tuning range. 
Specific center frequency tuning information can be obtained 


from information about the dynamic channel in use. It 


is 


assumed that both center frequency and bandwidth (Q) tuning can 


be done without causing faults in existing signals. 
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SIMPLE LABEL and CHANNEL COUNT: In this case, the accompanying 
label set and MaxNumChannels indicate labels permitted on the 
port and the maximum number of labels that can be 
simultaneously used on the port. 


LINK LABEL EXCLUSIVITY: A label (wavelength) can be used at most 
once among a given set of ports. The set of ports is specified 
as a parameter to this constraint. 


Restriction-specific parameters are used with one or more of the 
previously listed restriction types. The currently defined 
parameters are: 


LabelSet is a conceptual set of labels (wavelengths). 


MaxNumChannels is the maximum number of channels that can be 
simultaneously used (relative to either a port or a matrix). 


LinkSet is a conceptual set of ports. 


MaxLabelRange indicates the maximum range of the labels. For 
example, if the port is a "colored" drop port of a ROADM, then there 
are two restrictions: (a) CHANNEL COUNT, with MaxNumChannels - 1, and 
(b) SIMPLE WAVELENGTH, with the wavelength set consisting of a single 
member corresponding to the frequency of the permitted wavelength. 
See [Switch] for a complete waveband example. 


This information model for port wavelength (label) restrictions is 
fairly general in that it can be applied to ports that have label 
restrictions only or to ports that are part of an asymmetric switch 
and have label restrictions. In addition, the types of label 
restrictions that can be supported are extensible. 


6.6.1. Port-Wavelength Exclusivity Example 


Although there can be many different ROADM or switch architectures 
that can lead to the constraint where a lambda (label) maybe used at 
most once on a set of ports, Figure 3 shows a ROADM architecture 
based on components known as Wavelength Selective Switches (WSSes) 
[OFCO8]. This ROADM is composed of splitters, combiners, and WSSes. 
This ROADM has 11 output ports, which are numbered in the diagram. 
Output ports 1-8 are known as drop ports and are intended to support 
a single wavelength. Drop ports 1-4 output from WSS 2, which is fed 
from WSS 1 via a single fiber. Due to this internal structure, a 
constraint is placed on the output ports 1-4 that a lambda can be 
used only once over the group of ports (assuming unicast and not 
multicast operation). The output ports 5-8 have a similar constraint 
due to the internal structure. 
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Figure 3: A ROADM Composed from Splitter, Combiners, and WSSes 
Dynamic Components of the Information Model 


In the previously presented information model, there are a limited 
number of information elements that are dynamic, i.e., subject to 
change with subsequent establishment and teardown of connections. 
Depending on the protocol used to convey this overall information 
model, it may be possible to send this dynamic information separately 
from the relatively larger amount of static information needed to 
characterize WSONs and their network elements. 
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7.1. Dynamic Link Information (General) 


For WSON links, the wavelength availability and which wavelengths are 
in use for shared backup purposes can be considered dynamic 
information and hence are grouped with the dynamic information in the 
following set: 


<DynamicLinkInfo> ::= <LinkID> 
<AvailableLabels> 
[<SharedBackupLabels>] 


AvailableLabels is a set of labels (wavelengths) currently available 
on the link. Given this information and the port wavelength 
restrictions, one can also determine which wavelengths are currently 
in use. This parameter could potentially be used with other 
technologies that GMPLS currently covers or may cover in the future. 


SharedBackupLabels is a set of labels (wavelengths) currently used 
for shared backup protection on the link. An example usage of this 
information in a WSON setting is given in [Shared]. This parameter 
could potentially be used with other technologies that GMPLS 
currently covers or may cover in the future. 


Note that the above does not dictate a particular encoding or 
placement for available label information. In some routing 
protocols, it may be advantageous or required to place this 
information within another information element such as the Interface 
Switching Capability Descriptor (ISCD). Consult the extensions that 
are specific to each routing protocol for details of placement of 
information elements. 


7.2. Dynamic Node Information (WSON Specific) 
Currently the only node information that can be considered dynamic is 
the resource pool state, and it can be isolated into a dynamic node 
information element as follows: 
<DynamicNodeInfo> ::= <NodeID> [<ResourcePool>] 

8. Security Considerations 
This document discusses an information model for RWA computation in 
WSONS. From a security standpoint, such a model is very similar to 
the information that can be currently conveyed via GMPLS routing 


protocols. Such information includes network topology, link state 
and current utilization, as well as the capabilities of switches and 
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routers within the network. As such, this information should be 
protected from disclosure to unintended recipients. In addition, the 
intentional modification of this information can significantly affect 
network operations, particularly due to the large capacity of the 
optical infrastructure to be controlled. A general discussion on 
security in GMPLS networks can be found in [RFC5920]. 
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